1. Field of the Invention
This invention relates to the Internet, more particularly to methods and apparatus for producing and using portals and portlets in web applications to provide enhanced capabilities for web sites.
2. Background of the Invention
The World Wide Web brought a major paradigm shift to communications over the Internet, conveying graphical information to users. With the advent of the Web there was and still is demand for increasing communicability and broad connectivity.
The Portal (previously known as a web portal) has brought a paradigm shift in internet space. A web site that offers an array of resources or services such as email, forums, search engines, databases or other information may be considered to be a portal. The first web portals may have been online services. For the first time, users surfing the internet were able to see web pages that were assembled with and offered information coming from various sites in the world wide web, yet the aggregation's constitution was transparent to the user. A user making use of a typical web browser sees a cohesive web page displayed. The origination of different parts of the page from various internet sites not associated with the web site being viewed is not readily apparent. These parts are termed Portlets.
Portlets are the visible active components end users see within their portal pages. Similar to a window in a PC desktop, each portlet “owns” a portion of the browser or Personal Digital Appliance screen where it displays results.
From a user's view, a portlet is a content channel or application to which a user subscribes, adds to their personal portal page, and configures to show personalized content.
From content providers' view, a portlet is a means to make available their content.
From a portal administrator's view, a portlet is a content container that can be registered with the portal, so that users may subscribe to it.
From a portal's point of view, a portlet is a component rendered into one of its pages.
From a technical point of view, a portlet is a piece of code or a small application that runs on a portal server and provides content that is to be embedded into portal pages. In the simplest terms, a portlet may be a Java™ servlet that operates inside a portal.
Each part (portlet) of a given page (typically sourced from different places in the world wide web) can collaborate with another part (portlet) of the same page to achieve higher function for a user surfing or accessing the page. Thus, a portal becomes the single point of access for multiple users, via multiple channels, to multiple sources of information.
Portals can be applied in various business models, namely: business to consumer, business to business, or business to enterprise. The key to quick adoption of the portal paradigm ties strongly to its ability to integrate existing web application data into the portal framework in a seamless fashion.
However, various technical hurdles still exist for such seamless web application integration into portal.
There are limitations in the prior art concerning how the following portal artifacts work together with existing web applications. The implementation of integration of web applications into portal architecture is not well defined. These entities include:
Original http request to a portal;
A portlet session within a portal;
A http request from the portal to the pertinent web application.
When different users access a portal page, the original http request for each user is directed towards the portal server (a). The original http session for each user is also entirely “owned” by the portal server. Each of the portlets has its own independent session called a portlet session. When a portlet needs to render information that comes from a given web application, (b), there are typically the following technical hurdles:                i. There is no existing mechanism for a portlet to generate http requests and responses to and from the backend web application.        j. There is no existing mechanism to manage multiple requests and responses to a calling portlet (and the portlet session) mapping correctly with multiple requests and responses to a backend web application (and the web application's session). Each (both portlet and web application) maintains its user session accordingly.        
This gets complicated when multiple portlets call the same web application, with the web application treating these multiple portlets requests within the same web application session.                k. There is no existing mechanism to relay session information between the multiple portlet sessions and the web application's session.        
When a well defined set of portlets within the same portlet application interact with the one web application at the backend, all the participating portlets must be able to retrieve and forward the correct session information to the web application at the backend such that the information rendered from the web application is consistent with the setting of that of the portal of the portlets. Examples of such setting includes locale information, user agent of that particular access etc. For example, the responses sent from the web application must be using the same locale with the portlet in the portal server who displays it.
There is no existing mechanism for single sign on such that the portal user's credentials will not be challenged by the backend web application. This is a critical requirement. The absence of it will result in the user's credentials being challenged when the user moves from one part of a web page to a different part of the same web page; as the portlets have different originations and identification requirements.
There is no existing mechanism for synchronization of multiple requests or responses between portlets of a given portlet application and the pertinent web application backend.
The prior art has limitations concerning how multiple portlets within the same portlet application can collaborate with one another (sharing the same context) as well as with the various integrated web applications dynamically is not defined.
One Usage Scenario involving multiple portlets collaborating by sharing the same ‘context’ dynamically will serve to conceptually illustrate the limitation:
With three portlets being displayed on the same portal web page:                one portlet shows the account summary by displaying a list of accounts        the second portlet shows a given account's list of outstanding invoices        the third portlet shows a given account's order history summary        
The second and the third portlets are contextually bound to the first portlet dynamically, reflecting outstanding invoices (2nd portlet) and order history (3rd portlet) and are synchronized with an account selected from the account list of the first portlet.
Limitations of the prior art:                i. No mechanism exists to define a sub-grouping of portlets within a portlet application that would work collaboratively.        j. No mechanism exists to define a context (that can be dynamically changed) shared among this sub-group of portlets within a given portlet application: example of context here is the selected account in portlet 1, such account selection can be changed dynamically.        k. No mechanism exists to detect the change in context dynamically: example of the change of selection from one account to another account from the account list in portlet 1 of the above example.        l. No mechanism exists to register a predefined action (or responses) for each participating portlets within the sub-group of portlets that share the same context: example of displaying the list of outstanding invoices (action in portlet 2) when the context is changed (from one account selection to another in portlet 1).        m. No mechanism exists to relay that dynamic context to the relevant integrated web applications        
There is no mechanism existing in the prior art to define a refresh sequence for a group of portlets within a portlet application                i. There is no provision today for a portal designer to specify the refresh order of a given set of portlets being displayed.        In our scenario above, the portal designer would want to have the first portlet (account list) refreshed first, the second portlet refreshed second etc. so that the 2nd and the 3rd portlets automatically have. Defined actions (when the portlet is deployed) taking place in a correct sequence.        
There is a lack of a well defined mechanism in portal architecture to support the aggregation of portlets based on business rule and user profiling information including the users' role.                i. There is no existing mechanism to define aggregation of portal resources per user based on business rules.        Example: all teenage portal users see one group of portlets, all senior portal users see another group of portlets.        j. There is no existing mechanism for such rule based and user based aggregation of portlets that is performed dynamically at runtime.        
There is no sharing of portal level business rules and user profile information with pertinent integrated back end web applications.
There is no sharing of business rules or user segmentation information with an integrated web application such that these rules and user segmentation can be consistent across a portal and its integrated backend web application. For example, if there is a rule defining the age range of a teenager, such a rule should be visible and applicable to the integrated web application for consistency.
Terminology
Portlets
Portlets are the visible active components that the end users see within their portal web pages. Similar to a window in a PC desktop, each portlet “owns” a portion of the browser or PDA (Personal Digital Appliance) screen where it displays portlet specific information.
Portlet Application
Portlets can also be grouped together in a portlet application. Portlet applications are distributed and deployed using Web archive files (WAR). There are portlet specific extensions to the standard Web application deployment descriptor.
Portlet Messages
Portlet messages are used for the communication between two portlets using portlet actions and portlet messages. The sending portlet creates a portlet action, encodes the action into a URL. When the URL is addressed, e.g. by a user trying to accomplish a task, the action listener is called and sends a portlet message to send the necessary data.
Portlet Session
A Portlet session is created for each portlet instance for each user logging on to maintain session information for each user per portlet instance.
Portlets of a given portlet application have limitations today concerning how multiple portlets within the same portlet application can collaborate with one another, sharing the same context, such these portlets that render responses from the integrated web application are able to render content dynamically related to the context in effect.
There is also no mechanism today to define subgroup of portlets within a given portlet application to work collaboratively in such a manner that no code change of the participating portlets is required. There is also no mechanism to detect the change in context dynamically nor is there mechanism today to register a predefined action for the participating portlets, including mechanism to relay that dynamic context to the relevant integrated web application.